Currently, it is typical that the inner workings of a software program contains errors inside of a large datapaths, statepaths, or userpaths. To identify these errors, points of interest in the system process must be identified. There are usually many different procedures in the software's source code that perform actions necessary for a single feature to operate, and each of these procedures needs to be inspected when a feature malfunctions. The person attempting to fix the error is frequently faced with a problem of having either too many debugging inspectors exposed, extending the time required to identify the points of interest among the mass of information, or too few debugging inspectors exposed, which does not give enough information to identify the points of interest.
As the complexity of a software program increases, the amount of time that it takes an author to identify a bug increases quickly because there are more combinations of points of interest that the person searching for the error must parse through. This is a common debugging problem generally known as information overload.
There are several common debugging techniques to report software artifacts for the purpose of identifying points of interest in software. Some of those techniques include adding tracers inside the source code that output specific information that they believe can lead to identifying points of interest in the software; setting up a variable watch list that outputs the current value or values of internal data structure instances; setting up break points that causes the code to stop at selected points during the execution, enabling the developer to review the artifacts and choose the next debugging action one step at a time; and viewing a stack trace that shows the current hierarchy of procedures that are executing during a break point. These techniques can be very time consuming, and frequently cause some errors to hide the existence of other errors, adding to the time required to fix errors. They additionally are frequently used in “debug builds” and not in “release builds”. Thus, once the build has gone to production, the developer loses the ability to debug the application.
When software is used to run a live, massively multi-user event such as webcasting and virtual tradeshows, it is a critical to monitor and fix problems immediately, and before the conclusion of the limited time event. This requires that no slowdown is caused by information overload, and no slowdown is caused by a communications bottleneck in gaining useful information about useful software artifacts. It also does not allow for the use of separate release builds, or any of the time intensive methods of the debug systems listed above.